代码仓
中

openUBMC单BCU双host特性设计说明书

所属SIG组:hardware-sig
落入版本:25.12
设计人员:黄雷生
日期:2025.9.11

Copyright © 2025 openUBMC Community

您对"本文档"的复制,使用,修改及分发受木兰宽松许可证, 第2版协议(以下简称"MulanPSL2")的约束。 为了方便用户理解,您可以通过访问https://license.coscl.org.cn/MulanPSL2了解MulanPSL2的概要 (但不是替代)。 MulanPSL2的完整协议内容您可以访问如下网址获取:https://license.coscl.org.cn/MulanPSL2。

改版记录

日期修订版本修订描述作者审核
2025-9-11V1.0初版黄雷生无

目录

  1. 特性概述

1.1 目的

1.2范围

1.3特性需求列表

  1. 需求场景分析

2.1特性需求来源与价值概述

2.2特性场景分析

2.3特性影响分析

2.3.1硬件限制

2.3.2技术限制

2.3.3对License的影响分析

2.3.4对系统性能规格的影响分析

2.3.5对系统可靠性规格的影响分析

2.3.6对系统兼容性的影响分析

2.3.7与其他重大特性的交互性,冲突性的影响分析

2.4同类社区/商用软件实现方案分析

  1. 特性/功能实现原理(可分解出来多个Use Case)

3.1目标

3.2总体方案

  1. Use Case一实现

4.1设计思路

4.2约束条件

4.3详细实现(从用户入口的模块级别或进程级别消息序列图)

4.4子系统间接口(主要覆盖模块接口定义)

4.5子系统详细设计

4.6DFX属性设计

4.6.1性能设计

4.6.2升级与扩容设计

4.6.3异常处理设计

4.6.4资源管理相关设计

4.6.5小型化设计

4.6.6可测性设计

4.6.7安全设计

4.7系统外部接口

4.8自测用例设计

  1. Use Case二实现

  2. 可靠性&可用性设计

6.1冗余设计

6.2故障管理

6.3过载控制设计

6.4升级不中断业务

6.5人因差错设计

6.6故障预测预防设计

  1. 安全&隐私&韧性设计

7.1Low Level威胁分析及设计

7.1.12层数据流图

7.1.2业务场景及信任边界说明

7.1.3外部交互方分析

7.1.4数据流分析

7.1.5处理过程分析

7.1.6数据存储分析

7.1.7缺陷列表

7.2隐私风险分析与设计

7.2.1隐私风险预分析问卷

7.2.2隐私风险预分析总结

7.2.3个人数据列表

7.2.4XX需求设计

7.2.5YY需求设计

  1. 特性非功能性质量属性相关设计

8.1可测试性

8.2可服务性

8.3可演进性

8.4开放性

8.5兼容性

8.6可伸缩性/可扩展性

8.7 可维护性

8.8 资料

  1. 数据结构设计(可选)

  2. 参考资料清单

表目录

表1:特性场景相关性分析

表2:特性需求列表

图目录

图1:单BCU双host架构总体实现原理图

图2:双host管理流程示意图

List of abbreviations 缩略语清单 :

Abbreviations 缩略语Full spelling 英文全名Chinese explanation 中文解释
BCUBasic Computing Unit基板计算组件
BMCBaseboard Management Controller基板管理控制器
IPMIIntelligent Platform Management Interface智能平台管理接口
hostHost System主机系统

1.特性概述 ​

【关键内容】 介绍openUBMC单BCU双host特性定位,对于特性面向的使用客户和市场范围,基于需求分析明确说明特性设计要达成的目的。

【参考输入】 无

【参考说明】

本特性主要面向国内头部互联网公司提供单台服务器双host能力,可以大大提高设备的容错能力。相比较过去多host产品单BCU只能支持1个host,新产品可以支持单BCU双host的场景,也可以支持单BCU单host,满足客户灵活搭配单双host的需求。本方案主要介绍单个BCU基板管理控制器同时管理两个host主机的功能。

1.1目的 ​

【关键内容】

本文档作为openUBMC单BCU双host特性需求的分析指导,对单BCU双host管理功能进行设计,明确主要处理过程,作为后续软件开发人员、测试人员的指导。

注意: 后续章节基于实际情况进行灵活裁剪

1.2范围 ​

【关键内容】 描述单BCU双host特性主要包含的功能点:

表1 特性场景相关性分析

场景编号编号1编号2
场景名称单BCU双host复用同一BCU,支持单BCU单host
特性是否相关√√

1.3特性需求列表 ​

表2:特性需求列表

需求情况,简要介绍单BCU双host特性,解决客户的高密度服务器管理场景诉求

表2 特性需求列表

需求编号需求名称特性描述文档名特性描述备注
3341755支持双主机SMBIOS通讯管理NA同一个BCU,单系统情况下与1个SMBIOS通讯,双系统情况下与2个SMBIOS通讯
3341759支持双主机BIOS固件管理NA同一个BCU,单系统情况下管理1个BIOS,双系统情况下管理2个BIOS
3348478支持双主机场景下BIOS PFR功能NA支持缓存包存储;支持上电前bios镜像异常后自愈恢复;支持校验通过后才上电

2.需求场景分析 ​

2.1特性需求来源与价值概述 ​

新产品支持同一BCU既能支持双host配置,也能支持单host配置,减少硬件成本

2.2特性场景分析 ​

【关键内容】

1)场景触发条件及对象:什么角色/工具/接口等在什么具体情况下使用该特性,使用对象技能如何?

2)描述该特性主要有哪些用户应用场景、子场景及关键任务操作。_

【关键内容】

  1. 使用者
  2. 时间,频率
  3. 关键任务
使用者时间/频率关键场景/任务/场景
算力管理组件BMC启动阶段CPU、Memory等与系统相关的对象正常呈现在资源协作接口上,且path的SystemId符合单双host配置情况
bios组件BMC启动阶段Bios、SmBios等于系统相关的对象正常呈现在资源协作接口上,且path的SystemId符合单双host配置情况

2.3特性影响分析 ​

描述该特性在整个系统中的位置及周边接口。描述该特性有哪些关键约束或特性冲突。

与其他需求及特性的交互分析:参考multihost需求,保证不同的sr加载时传入对应Systemid

平台差异性分析:不涉及

兼容性分析:涉及CSR拆分,需要考虑兼容问题

约束及限制:需要硬件领域明确BCU上硬件对象的系统归属

2.3.1硬件限制 ​

简单描述承载子系统的硬件约束,主频,内存,线程数及其它对软件有影响的硬件特点

如有,给出规避方案。 不涉及

2.3.2技术限制 ​

操作系统:

编程语言:

如有,给出规避方案。 不涉及

2.3.3对License的影响分析 ​

明确对特性所涉及技术的合规性、所引入的第三方开源软件的 license 的影响分析。 不涉及

2.3.4对系统性能规格的影响分析 ​

明确系统容量规格,基于特性运行资源的设定条件。比如至少需多少 G 内存才能使用此特性 不涉及

2.3.5对系统可靠性规格的影响分析 ​

特性对于可靠性指标的假设和约束,例如在预设的条件下要支持 x 个 9 的目标等。 不涉及

2.3.6对系统兼容性的影响分析 ​

是否会影响数据库的前向兼容,也就是用户在数据库旧版本使用的特性在新版本上是否依然可以使用。 当csr拆分后,与system相关的csr需要内置。如果E2P上存储的是原始csr,会导致对象重复分发。可以关注当前产品是否已经发货,现网是否有此场景

2.3.7与其他重大特性的交互性,冲突性的影响分析 ​

分析包括周边工具、其他内核特性的交互和影响 不涉及

2.4同类社区/商用软件实现方案分析 ​

该特性在同类社区 / 商用软件上的实现机制,对比分析,体现优劣性对比 不涉及

3.特性/功能实现原理(可分解出来多个Use Case) ​

3.1目标 ​

该章节主要描述特性在什么场景下要实现什么规格、达到什么目标 通过拆分sr的方式,支持与system相关的对象在单host场景下以1个systemid的方式加载,在双host场景下以2个systemid的方式加载

3.2总体方案 ​

该章节主要阐述该特性的详细设计,包括选择什么硬件、使用什么算法、架构如何布局等

从整体流程上,根据场景分析和系统分解,将特性实现分为多个关键场景( Use Case )

定义对接的原则

方案整体架构图

SR按照多系统解耦示意图,框内部分需要内置到BMC中

4.Use Case一实现 ​

4.1设计思路 ​

说明 Use Case 实现的思路 软件类功能可以考虑复用multihost需求已实现能力,本需求与multihost的差异点主要体现在对硬件的访问上。重点关注与访问bios flash相关功的能,如bios升级

4.2约束条件 ​

描述前提条件,即该功能开启的限制条件,比如会导致系统 xx 功能不可用,比如在 xx 内存限制下才能开启等。 需要在PSR中增加全局配置,区分是单host还是双host

4.3详细实现(从用户入口的模块级别或进程级别消息序列图) ​

本章节具体描述 Use Case 实现过程。使用时序图、流程图描述各模块间的交互过程。

同时用简短文字说明时序图、流程图的各个模块分配需求的变化,尽量使用结构化的语言。 不涉及具体Use Case

4.4子系统间接口(主要覆盖模块接口定义) ​

在这个章节只要说本次修改涉及哪个 .h 的哪个接口的修改,大致的修改内容简述下即可。 不涉及

4.5子系统详细设计 ​

详细描述各模块的修改点。 不涉及

4.6DFX属性设计 ​

4.6.1性能设计 ​

特性是否影响已有的相关性能指标,是否会影响现有特性的性能,如何保证新特性的性能 SR加载过程增加额外判断,可能会影响启动性能,但理论上影响不会超过1s

4.6.2升级与扩容设计 ​

特性是否会影响到升级和扩容 不涉及

4.6.3异常处理设计 ​

有哪些异常场景,是否有规避方案,怎么提示用户,如何保证用户业务影响最小 不涉及

4.6.4资源管理相关设计 ​

是否占用额外的内存、磁盘 I/O 、网络 I/O 等资源,资源占用规格是什么,如果资源超出环境限制后,是否有处置措施 不涉及

4.6.5小型化设计 ​

请说明特性是否会影响小型化版本的规格(内存使用、安装包大小、 CPU 占用等),如果影响,是否有调整优化手段或者使用宏隔离。 不涉及

4.6.6可测性设计 ​

特性是否具备可测试性,给出测试应该涵盖的功能、性能、安全、可靠性等方面,涵盖边界值、异常场景等。 不涉及

4.6.7安全设计 ​

有哪些会影响数据库或者 OS 安全的地方,比如用户权限管理、秘钥管理、网络协议、外部攻击等。 不涉及

4.7系统外部接口 ​

是否会影响到系统外部接口,包括 guc 参数、工具使用方式、 SQL 语法、网络协议、系统表视图函数、驱动( JDBC/ODBC )等 不涉及

4.8自测用例设计 ​

描述自测用例是如何设计的,如何测试保证功能符合预期 不涉及

5.Use Case二实现 ​

不涉及

6.可靠性&可用性设计 ​

6.1冗余设计 ​

特性设计考虑的冗余主要是系统采用了冗余设计,特性需要考虑镜像备份、配置参数备份和主备冗余系统之间进行数据同步等信息。

特性设计时,需要给出备份的关键配置参数清单,主备冗余系统之间进行数据同步时间 / 策略和关键数据清单,主备切换时数据核查机制 / 脏数据处理策略、备份恢复策略等。

对于镜像式备份,如快照 /checkpoint 机制,需要给出备份周期、数据核查机制 / 脏数据处理策略、恢复策略等,对系统性能有明显影响的特性,需要给出设计约束条件。 不涉及

6.2故障管理 ​

故障管理包括故障检测、故障隔离、故障定位、故障恢复和相互关联的设计。

特性的故障管理,主要是特性自身的故障检测、告警 / 日志设计、故障恢复以及故障接口设计。

故障管理通常的设计原则包括:

  1. 故障全面快速检测通常考虑检测范围、备用检测、检测速度、检测影响;
  2. 控制失效影响范围通常考虑多平面、多粒度、隔离单位等隔离域划分;
  3. 故障快速恢复通常考虑自动恢复、优先恢复、分级复位、无耦合恢复、分层保护等策略。

故障管理常见的设计模式包括 RollBack 模式、故障 Bypass 、断路器模式、隔离仓模式等。 不涉及

6.3过载控制设计 ​

特性的过载控制设计需要考虑特性内处理业务的流量检测、检测位置和业务丢弃位置、业务丢弃时响应的业务消息信息,以及与统一的过载控制机制之间的调用、被调用关系、接口。

特性内部简单的过载控制机制通常采用限速的方式,需要考虑限速的位置、默认限速值、日志告警等信息。

过载控制通常的设计原则包括动态限流、弹性扩缩容、先负载均衡后流控、尽早控制、优先级保障、优雅降级设计等:

  1. 尽早控制:系统过载时,应尽可能在业务流程处理前端或业务处理较早的处理模块上控制业务接入,避免中间控制带来不必要的性能消耗;
  2. 优先级保障:系统过载时保证高优先级的业务能够优先获得资源,优先得到处理,从而保证社会效益最大化;
  3. 优雅降级设计:非核心业务降级、核心功能放通、体验降级等。 不涉及

6.4升级不中断业务 ​

特性内部的升级不中断业务,主要考虑特性在不同软件版本的消息兼容、配置数据格式兼容、接口兼容、与周边特性的相互依赖,以及升级失败时的快速回退处理过程。 不涉及

6.5人因差错设计 ​

特性的人因差错主要考虑特性涉及的命令、操作、配置文件 / 数据等人机接口的错误防护,通常考虑如下几个方面:

  1. 删除、破坏性修改需要提供高危提示以及二次确认,页面焦点默认"取消"。用户可见接口( cli 以及 web 页面)都需要考虑,包括开源组件提供的命令接口;
  2. 对重启节点操作需要提前检查是否影响客户 VM 运行,给出明确提示建议操作;
  3. 所有高危操作需要记录审计日志;
  4. 预防配置错误、预防硬件误操作、操作执行前的系统检查和操作错误后的快速回退。

人因差错通常的设计原则包括:

  1. 角色约束:通过权限控制设计预防对不同角色的配置范围进行约束,避免越权配置导致错误;
  2. 配置校验:通过配置生效机制设计确保在配置生效前进行必要的校验,避免错误配置生效;
  3. 备份恢复:通过配置数据备份与恢复设计确保在出现配置错误时能够快速恢复到正确的配置数据状态。 不涉及

6.6故障预测预防设计 ​

特性应配合系统故障预测预防能力提供相关的数据采集和统计接口。比如磁盘空间检测等。 不涉及

7.安全&隐私&韧性设计 ​

7.1Low Level威胁分析及设计 ​

本节不涉及

7.1.12层数据流图 ​

7.1.2业务场景及信任边界说明 ​

7.1.3外部交互方分析 ​

7.1.4数据流分析 ​

7.1.5处理过程分析 ​

7.1.6数据存储分析 ​

7.1.7缺陷列表 ​

7.2隐私风险分析与设计 ​

7.2.1隐私风险预分析问卷 ​

7.2.2隐私风险预分析总结 ​

当前版本不涉及个人数据收集,因此该版本无需做隐私风险分析。

7.2.3个人数据列表 ​

本特性不涉及个人数据收集和处理。

7.2.4XX需求设计 ​

不涉及

7.2.5YY需求设计 ​

不涉及

8.特性非功能性质量属性相关设计 ​

8.1可测试性 ​

重点从特性在测试的方向和规格上展开描述,说明在测试人员测试时应该测哪些方面,需要注意哪些边界值、异常值、异常场景。 不涉及

8.2可服务性 ​

对特性提供丰富的可维护可服务的措施,提供对特性的使用、维护、问题处理等的完整资料说明。 不涉及

8.3可演进性 ​

重点从特性架构、功能的可演进性上展开描述。 不涉及

8.4开放性 ​

重点描述特性的对外接口开放性,包括接口的规范性,比如符合 SQL 2011 标准。 不涉及

8.5兼容性 ​

重点描述特性是否会影响系统的前向兼容性,即旧功能在升级新版本之后是否可使用,使用行为是否和旧版本保持一致。 不涉及

8.6可伸缩性/可扩展性 ​

有效满足系统容量变化的要求,包括数据库节点的扩缩容、数据库服务器本身的扩缩容。 不涉及

8.7可维护性 ​

重点从特性的可维护性展开描述,比如诊断视图、 log 打印等。 不涉及

8.8资料 ​

无

9.数据结构设计(可选) ​

本章节完成数据库结构的设计(数据库系统表结构,可以使用 Power Designer 完成),可选章节。 不涉及

10.参考资料清单 ​

无